In current multi tenancy systems, shared data is data that is used by all tenants. The shared data comprises the software of the platform product and runtime objects, shared monitoring data and the like. Each tenant has its own software data, metadata defining its processes, and business transaction data.
Conventionally, upgrading of all tenants of a multi-tenancy computing system are known, rather than upgrading of individual tenants. Thus, conventional upgrading a system operates on the system wide data (data shared in the system by all tenants) and on the data of each system. Conventional upgrade procedures cannot separately upgrade the shared data and the data of a single or several tenants, it always jointly upgrades the shared data and all data in all tenants. Tenant move operations may include moving one or all tenants from one computing system implementing a version of an enterprise application suite and associated data to another multi-tenancy computing system implementing the same version of the enterprise application suite and associated data. Herein, a version of enterprise application suite and associated data may also be referred to as a version of software, or a software version. In order to upgrade a computing system, the shared data is upgraded and the tenants are jointly upgraded. A conventional tenant operation procedure allows movement of a tenant from one computing system to another computing system only if the one computing system and the other computing system have the same software version.
However, there can be situations that require upgrading of an individual tenant rather than a collective upgrading of all tenants on a multi-tenancy computing system. But, an individual tenant upgrade is unknown for tenants of a multi-tenancy computing system. Until now, this can only be achieved as follows: move one tenant to a new system having no tenant yet and upgrading the new system with the moved-in tenant. Procedures such as these create high costs per tenant.
In some conventionally known implementations, customers are required to actively participate in the upgrade. Since a customer is involved in the upgrade, the timeslot where the upgrade shall take place needs to be planned individually for each customer. With the current upgrade procedure, where all tenant in one system are upgraded simultaneously with the upgrade of the system, customer individual upgrade scheduling is not possible.
During most such upgrades, manual implementations may result in many errors in tenant specific actions. Thus, in computing systems having a large number of tenants, the likelihood of a failure of the upgrade of a system including the simultaneous upgrade of all tenants increases dramatically. For example, for a computing system with 100 tenants to complete an upgrade of all the tenants all-at-once with a success rate above 90%, a failure rate for each tenant needs to be less than 0.1%.